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Abstract 


This document updates RFC 5066. It amends that specification by 
informing the Internet community about the transition of the 
EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub 
MIB Working Group to the Institute of Electrical and Electronics 
Engineers (IEEE) 802.3 working group. 
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SIFON Ol S O E 


1. Introduction 
RFC 5066 [RFC5066] defines two MIB modules: 


EFM-CU-MIB, with a set of objects for managing 10PASS-TS and 
2BASE-TL Ethernet in the First Mile Copper (EFMCu) interfaces; 


IF-CAP-STACK-MIB, with a set of objects describing cross-connect 
capability of a managed device with multi-layer (stacked) 
interfaces, extending the stack management objects in the 
Interfaces Group MIB and the Inverted Stack Table MIB modules. 


anannark WW WN 


With the conclusion of the [HUBMIB] working group, the responsibility 


for the maintenance and further development of a MIB module for 
managing 2BASE-TL and 10PASS-TS interfaces has been transferred to 
the Institute of Electrical and Electronics Engineers (IEEE) 802.3 
[IEEE802.3] working group. In 2011, the IEEE developed the 
TEEE8023-EFM-CU-MIB module, based on the original EFM-CU-MIB module 


[RFC5066]. The current revision of IEEE8023-EFM-CU-MIB is defined in 


IEEE Std 802.3.1-2013 [IEEE802.3.1]. 


The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules can coexist. 
Existing deployments of the EFM-CU-MIB need not be upgraded, but 


operators using the MIB should expect that new equipment will use the 


ITEEE8023-EFM-CU-MIB. 


Please note that the IF-CAP-STACK-MIB module was not transferred to 
IEEE and remains as defined in RFC 5066. This memo provides an 
updated security considerations section for that module, since the 
original RFC did not list any security considerations for 
IF-CAP-STACK-MIB. 
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The Internet-Standard Management Framework 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to section 7 of 
RFC 3410 [RFC3410]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in RFC 
2119 [RFC2119]. 


Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB 


The current version of IEEE8023-EFM-CU-MIB, defined in IEEE Std 
802.3.1-2013, has MODULE-IDENTITY of ieee8023efmCuMIB with an object 
identifier allocated under the { iso(1) 
iso-identified-organization(3) ieee(111) 
standards-—association-numbered-series-standards (2) lan-man-stds (802) 
ieee802dot3(3) ieee802dot3dotlimibs(1) } sub-tree. 


The EFM-CU-MIB has MODULE-IDENTITY of efmCuMIB with an object 
identifier allocated under the mib-2 sub-tree. 


The names of the objects in the first version of the 
TEEE8023-EFM-CU-MIB are identical to those in the EFM-CU-MIB. 
However, since both MIB modules have different OID values, they can 
coexist, allowing the management of the newer IEEE MIB-based devices 
alongside the legacy IETF MIB-based devices. 


Updating the MIB Modules 


With the transfer of the responsibility for maintenance and further 
development of the EFM-CU-MIB module to the IEEE 802.3 working group, 
the EFM-CU-MIB defined in RFC 5066 becomes the last version of that 
MIB module. 


All further development of the EFM Copper Interfaces MIB will be done 
by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. 
Requests and comments pertaining to EFM Copper Interfaces MIB should 
be sent to the IEEE 802.3.1 task force, currently chartered with MIB 
development, via its mailing list [LIST802.3.1]. 


The IF-CAP-STACK-MIB remains under IETF control and is currently 
maintained by the [OPSAWG] working group. 
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Security Considerations 


There are no managed objects defined in the IF-CAP-STACK-MIB module 
with a MAX-ACCESS clause of read-write and/or read-create. So, if 
this MIB module is implemented correctly, then there is no risk that 
an intruder can alter or create any management objects of this MIB 
module via direct SNMP SET operations. 


Some of the readable objects in this MIB module (i.e., objects with a 
MAX-ACCESS other than not-accessible) may be considered sensitive or 
vulnerable in some network environments. 


In particular, ifCapStackStatus and ifInvCapStackStatus can identify 
cross-connect capability of multi-layer (stacked) network interfaces, 
potentially revealing the underlying hardware architecture of the 
managed device. 


It is thus important to control even GET and/or NOTIFY access to 
these objects and possibly to even encrypt the values of these 
objects when sending them over the network via SNMP. 


SNMP versions prior to SNMPv3 did not include adequate security. 
Even if the network itself is secure (for example by using IPsec), 
there is no control as to who on the secure network is allowed to 
access and GET/SET (read/change/create/delete) the objects in this 
MIB module. 


Implementations SHOULD provide the security features described by the 
SNMPv3 framework (see [RFC3410]), and implementations claiming 
compliance to the SNMPv3 standard MUST include full support for 
authentication and privacy via the User-based Security Model (USM) 
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations 
MAY also provide support for the Transport Security Model (TSM) 
[RFC5591] in combination with a secure transport such as SSH 
[RFC5592] or TLS/DTLS [RFC6353]. 


Further, deployment of SNMP versions prior to SNMPv3 is NOT 
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 
enable cryptographic security. It is then a customer/operator 
responsibility to ensure that the SNMP entity giving access to an 
instance of this MIB module is properly configured to give access to 
the objects only to those principals (users) that have legitimate 
rights to indeed GET or SET (change/create/delete) them. 
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